1. Field of the Invention
The present invention relates to a system having a plurality of modules connected through a common bus. In particular, the present invention relates to a method and apparatus for arbitration in a system that performs in-module arbitration such that the respective modules select one bus access command out of a plurality of bus access commands in this module, and which performs arbitration of a request on the bus in a distributed arbitration system.
2. Description of the Related Art
In a system in which respective modules perform arbitration of bus access commands for bus-requesting output from a plurality of modules, so as to acquire the bus consecutively, each respective module is required to perform arbitration of a bus access command to be requested next by the respective module after confirming the arbitration result on the bus of a bus request made by the respective module just prior to the present bus request. Depending on whether the result of the bus request is successful or unsuccessful, it is determined whether in-module arbitration is performed excluding the bus access command selected previously, or whether in-module arbitration is performed including the bus access command selected previously.
Heretofore, for a short cycle, it has been impossible to perform both bus arbitration and in-module arbitration in the same cycle, and both arbitrations require one cycle respectively, that is, total two cycles are needed. Therefore, the number of cycles required to issue one bus access command takes a long time, which is a problem. The conventional art is described hereinbelow.
The structure of the conventional art relating to in-module arbitration is shown in FIG. 4. In FIG. 4, the structure of one module 0 is shown, and other modules have the same structure. As shown in FIG. 4, the module 0 has a bus arbiter 306 for performing arbitration of a request on a bus and an in-module arbiter 302 for performing arbitration of a bus access command to be requested next by the involving module using the result of the previous request. A bus access command storage queue group 301 stores a plurality of bus access commands that this module is ready for requesting to the bus. For example, bus access command storage queue group 301 may include a plurality of FIFOs and/or registers, with each one being assigned a particular priority level and receiving bus access commands from a particular unit or element.
The in-module arbiter 302 selects the bus access command having the highest priority out of the bus access commands 313 in the bus access command storage queue group 301. However, if acquisition of the bus by this module is informed to this module by way of the bus WIN signal 312, then the bus access command selected previously is not selected.
The bus access command selected by the in-module arbiter 302 is stored in the request register 303. The request signal generating section 305 outputs a request including type of the bus access command stored in the request register 303 to the request line 304 that corresponds to this module, and which is output to all the modules on the bus. Request INPUT registers 307 to 309 are served for storing bus requests from all the modules on the bus including this module. The bus arbiter 306 selects the module that requests the bus access command having the highest priority as a bus WINNER. If the request of this module is selected, then the bus arbiter 306 asserts the bus WIN signal 310. The bus WIN signal storage register 311 receives and stores the bus WIN signal 310. In the case that a module is structured using a high speed operative LSI, it is impossible to perform bus arbitration and in-module arbitration in the same one cycle, therefore, a bus WIN storage register is needed for receiving temporarily the bus WIN signal.
The bus access command stored in the bus access command register 304 is outputted from the bus driving section 318 to the common bus 317 when the bus WIN signal 310 is asserted, and the issuance of the bus access command to the bus is completed.
A time chart for representing the bus condition in the conventional art is shown in FIG. 5. In the timing 1, the bus access command requested by the module to the bus is stored in the request register 303. Also in the timing 1, the request line 314 is asserted and the bus request is informed to all the modules on the bus. In the timing 2, the respective modules store the bus request in the request INPUT registers 307 to 309 to perform bus arbitration, and determine the bus WINNER. The bus access command in the bus access command register 304 is outputted to the bus as an ENB (enable) signal if this module has acquired the bus. In the timing 3, the bus WIN signal storage register 311 stores the bus WIN signal 310. The in-module arbiter 302 performs arbitration of the bus access command for a next bus request with reference to the value of the bus WIN signal storage register 311 in the timing 3.
In the prior art, it is required to send the bus WIN signal from the bus arbiter 306 to the in-module arbiter 302. However, in a high speed operative LSI, the in-module arbiter 302 cannot directly use the signal supplied from the bus arbiter 306, but it is required to use the signal through a one-step FF (bus WIN signal register 311). Because the bus arbiter 306 involves complex logic for performing arbitration of requests from the respective modules and also the in-module arbiter 302 involves complex logic for performing arbitration of the bus access command in the module, it is impossible to use directly the signal that has passed through the logic of the bus arbiter 306 for the in-module arbiter 302. Therefore, a one-step FF (bus WIN signal storage register 311) is necessary to be provided for supplying the bus WIN signal from the bus arbiter 306 to the in-module arbiter 302. As a result, the number of cycles required for possessing of one bus access command increases by one, and the bus access command processing capacity of the bus decreases, thereby causing a problem.